(網(wǎng)經(jīng)社訊)本文最初寫于兩年之前，是結(jié)合我個人的工作內(nèi)容以及過往職業(yè)生涯中從事企業(yè)應(yīng)用開發(fā)的十余年經(jīng)驗寫成的；近期做了重新整理和內(nèi)容補充。文中雖然沒有具體討論軟件架構(gòu)和技術(shù)細(xì)節(jié)，但包含了很多掃盲性質(zhì)的概念介紹以及我本人對企業(yè) IT 服務(wù)和云計算的一些思考。
企業(yè) IT 服務(wù)的困局
企業(yè) IT 服務(wù)已經(jīng)不是什么新鮮的業(yè)務(wù)模式了，從上世紀(jì) 80、90 年代開始，隨著計算機的廣泛應(yīng)用，企業(yè)信息化逐步成為一個被廣泛認(rèn)可的業(yè)務(wù)領(lǐng)域，專業(yè)的企業(yè)IT服務(wù)商也應(yīng)運而生。但與國外的企業(yè)IT服務(wù)商的飛速發(fā)展相比，國內(nèi)的企業(yè) IT 服務(wù)業(yè)務(wù)始終處于不溫不火的尷尬境況，這當(dāng)然與國內(nèi)企業(yè)客戶管理層的決策認(rèn)知以及實操環(huán)節(jié)的非技術(shù)因素有很大關(guān)系，但我認(rèn)為國內(nèi)企業(yè) IT 服務(wù)商自身的技術(shù)能力、產(chǎn)品戰(zhàn)略、商業(yè)模式同樣是造成這種困局的不可忽視的重要原因。
時至今日，國內(nèi)企業(yè) IT 服務(wù)領(lǐng)域最主要的商業(yè)模式還是外包。
企業(yè) IT 服務(wù)的外包時代
這種模式很容易理解。比如，A 公司需要用一套某個具體業(yè)務(wù)的信息化系統(tǒng)，但 A 公司并不是軟件公司，自己也沒有專職的開發(fā)人員，不能自主開發(fā)軟件，所以 A 公司將這項開發(fā)作為一個項目，外包給有能力做軟件開發(fā)的 B 公司。
這里邊最主要的矛盾在于：A 公司不懂軟件開發(fā)；B 公司不懂 A 公司的業(yè)務(wù)。于是，相互溝通中的各種誤解、偏差，在開發(fā)、測試、部署、驗收以及運維、增強的整個軟件項目生命周期中不停的發(fā)生、疊加，項目的工期越來越長、質(zhì)量越來越難控制，最后多半就是勉強上線、湊活能用。A 公司受困于無休止的系統(tǒng)問題（可能是功能設(shè)計問題，也可能是開發(fā)中的程序技術(shù)問題）；B 公司受困于無休止的需求變更（可能是真的需求變更，也可能是溝通上的誤解或者客戶描述的偏差、技術(shù)實現(xiàn)的偏差等等）；雙方的相關(guān)成本都與日俱增（最主要的就是反復(fù)溝通、反復(fù)修改測試以及一些實操上的手續(xù)等等）。
這些現(xiàn)象，在 A 公司、B 公司都沒有相關(guān)經(jīng)驗時，將變得非常容易發(fā)生，也非常影響項目的進展以及雙方的實際成本。于是，一種做“IT 咨詢”業(yè)務(wù)的 C 公司就慢慢產(chǎn)生了。C 公司既懂 A 公司的具體業(yè)務(wù)，也懂軟件開發(fā)的相關(guān)知識。這樣，C 公司可以幫助 A 公司做相關(guān)的需求、功能設(shè)計乃至 IT 規(guī)劃、IT 管理等等的相關(guān)工作；同時，C 公司又可以相對準(zhǔn)確、有效的與負(fù)責(zé)軟件開發(fā)的 B 公司進行具體的溝通、日常開發(fā)管理、驗收等工作；這在很大程度上就使這種軟件開發(fā)外包的模式逐漸專業(yè)化、產(chǎn)業(yè)化。
實際上，B 公司在進行了若干與 A 公司業(yè)務(wù)類似的項目之后，自己一般就有了經(jīng)驗，可以直接來做 C 公司的工作；這種能力，對于 B 公司來講，就可以被稱為“具有方案能力”。那么 B 公司與其他僅做軟件開發(fā)外包的公司相比，就有了一定的競爭優(yōu)勢。
對于技術(shù)能力比較強的B公司，多半會在與 A 公司類似的項目中發(fā)現(xiàn)大多數(shù)代碼都是“可復(fù)用的”，于是就會基于這些可復(fù)用的代碼構(gòu)建出具有具體業(yè)務(wù)功能的“產(chǎn)品”。之后就可以結(jié)合這種產(chǎn)品來給與A公司有類似業(yè)務(wù)的公司做所謂的“實施”，即針對客戶公司的特殊需求做一些定制開發(fā)或者模塊化的替換、增減來形成一個特定的業(yè)務(wù)系統(tǒng)。像金蝶、用友，在其發(fā)展歷程中都經(jīng)歷過這個過程。
同樣，C 公司因為有 IT 規(guī)劃、IT 管理、系統(tǒng)方案的能力，在資金允許的情況下，也可能會自己組建開發(fā)團隊來做 B 公司的工作。這樣，一種既具備 IT 規(guī)劃、方案能力，又具有軟件開發(fā)能力的公司就慢慢發(fā)展形成了，這就是所謂的“系統(tǒng)集成商”或者叫做“方案商”，它們的核心競爭力主要體現(xiàn)在 IT 規(guī)劃、方案以及大中企業(yè)客戶關(guān)系上（因為考慮到替換成本，大中企業(yè)在 IT 服務(wù)商的選擇上忠誠度是比較高的），具體的開發(fā)工作可能自己做，也可能再外包給僅做軟件開發(fā)的公司。
國內(nèi)系統(tǒng)集成商的代表有浪潮、東軟、中軟、太極、清華同方、神州數(shù)碼、東華軟件和航天信息等公司。它們當(dāng)中很多都是做計算機硬件起家，因而有了一定的企業(yè)客戶資源，之后在企業(yè)信息化過程中就自然而然的發(fā)展出了軟件交付、系統(tǒng)集成的能力。就國內(nèi)環(huán)境而言，客戶關(guān)系在業(yè)務(wù)發(fā)展過程中的作用相對會高于國外的環(huán)境（產(chǎn)品本身的技術(shù)競爭力有時并不是最重要的），這也是國內(nèi)這些大的系統(tǒng)集成商的一個共同特色。
外包模式的弊端
對于企業(yè)客戶來講，在這種模式之下，除了一次性的項目開發(fā)費用或產(chǎn)品實施費用以外，一般還需要花費相當(dāng)多的軟硬件購置、維護費用（例如服務(wù)器、數(shù)據(jù)庫產(chǎn)品、中間件、安全軟件乃至數(shù)據(jù)中心的構(gòu)建等等），以及為專門從事運行維護的人員（負(fù)責(zé)監(jiān)控 IT 系統(tǒng)、排除故障乃至一部分技術(shù)問題解決等等）所付出的人力成本。而這些成本則會成為企業(yè)的一個長期負(fù)擔(dān)。
很多大企業(yè)針對外包模式的成本問題，開始自己組建 IT 團隊，由自己的IT團隊來進行相關(guān)的技術(shù)方案選型、設(shè)計、實施、運維等必要的工作，同時自建數(shù)據(jù)中心管理自己的軟硬件。這當(dāng)然需要很高的持續(xù)投入，然而即使花了很多錢，其人員、設(shè)備和實施、運維過程的專業(yè)性往往仍然難以令人滿意，IT 事故一樣層出不窮。對于中小企業(yè)客戶而言，則受限于可投入的有限成本，而導(dǎo)致它們的IT系統(tǒng)通常都非常簡陋和不堪一擊。
隨著大中型企業(yè)自建 IT 團隊成為事實，一種從事“人力資源外包”業(yè)務(wù)的 D 公司也應(yīng)運而生了。這種商業(yè)模式非常簡單：D 公司通過長期勞動合同或者項目合同的方式招募技術(shù)人員，然后將這些人員外包到有技術(shù)人力資源需求的 A 公司去工作。對 A 公司來講，這只是短期性質(zhì)的的低廉人力成本，且單價大大低于自己招募同級別全職員工；對 D 公司而言，則可以簡單地、相對穩(wěn)定地賺取人力成本差價，而無需任何額外花銷。事實上，除了專門的人力資源公司，很多系統(tǒng)集成商、軟件外包公司也都有這種業(yè)務(wù)；因為理論上講，這種業(yè)務(wù)模式只需要客戶關(guān)系，而基本無需其他技術(shù)含量。這種模式的主要弊端則在于其對 A 公司的技術(shù)和管理能力要求較高，以及因為人員流動風(fēng)險而產(chǎn)生的對 A 公司業(yè)務(wù)、知識管理等方面的影響。
對于服務(wù)商來講，這種外包模式的成本開銷同樣巨大，因為“需求”永遠(yuǎn)在變，bug 永遠(yuǎn)在出，無休止的人力成本和溝通成本投入以及回款問題對其利潤空間的不斷擠壓使很多中小服務(wù)商不堪重負(fù)。沒有一些特定的資源或機會，正常操作的話，想“盈利”是非常困難的。服務(wù)商們只能不斷壓榨內(nèi)部成本，這也直接導(dǎo)致其自身的專業(yè)化、產(chǎn)品化、規(guī)?；蔀殡y以企及的空中樓閣。
盡管外包模式對于項目雙方都有很多弊端，但在相當(dāng)長的時間里，它都是非軟件企業(yè)的信息化建設(shè)的唯一選項；直到“云計算”的出現(xiàn)。
云計算的興起
云計算（Cloud Computing）的提法最早出現(xiàn)在 1996 年，但直到 10 年之后，Amazon 才在 2006 年 8 月發(fā)布了世界上第一個真正意義的云計算產(chǎn)品“Elastic Compute Cloud”。隨后在 2008 年 4 月，Google 也推出了著名云計算應(yīng)用引擎的“Google App Engine”；同年 10 月，微軟宣布將推出自己的云計算平臺Azure（Azure 的實際發(fā)布是在 2010 年 2 月）。
又經(jīng)過了大概 10 年左右，到 2016 年，云計算體系已經(jīng)相對發(fā)展成熟，它也為企業(yè)IT服務(wù)提供了一種新的可選方案。對服務(wù)使用方而言，云計算的主要優(yōu)點有：
云計算可以使用戶方便、快捷的添加、擴展、調(diào)整IT基礎(chǔ)設(shè)施資源（比如服務(wù)器的 CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)帶寬等等）。
使用成本的大幅度降低。因為云計算的模式，是由專業(yè)的云計算服務(wù)廠商提供軟硬件服務(wù)，客戶所要支付的僅僅是固定的、相對低廉的租賃費用，而不需要再去自己購置軟硬件、自己進行運行維護（構(gòu)建自己的數(shù)據(jù)中心）。
硬件設(shè)備和訪問位置的無關(guān)性。云計算廠商一般會在各個網(wǎng)絡(luò)運營商處都有相對優(yōu)化的接入點；而不像傳統(tǒng)的企業(yè)自管服務(wù)器，會受服務(wù)器所在地的網(wǎng)絡(luò)運營商的線路限制，導(dǎo)致跨地區(qū)、跨運營商訪問時的性能難以確保。
云計算廠商可以提供專業(yè)的監(jiān)控服務(wù)，無需自行購置相關(guān)的監(jiān)控軟硬件。
按需的自服務(wù)資源管理方式和高可伸縮性。就是用戶可以按照自己的實際使用量以自服務(wù)的方式調(diào)整所需的軟硬件資源，進一步降低使用成本；同時又可以快速的調(diào)整軟硬件資源需求。（比如在業(yè)務(wù)量較低時降低 CPU、內(nèi)存、帶寬等需求以節(jié)省成本，在應(yīng)用壓力增大時增加相關(guān)資源；或者由服務(wù)提供商自動根據(jù)應(yīng)用壓力調(diào)整所需資源。）
可度量的服務(wù)。所有對軟硬件資源的使用，都可以由服務(wù)提供商進行準(zhǔn)確的統(tǒng)計和報告。
云計算的服務(wù)模式，從概念上講，由低到高大概可以分為以下三個層級：
IaaS（Infrastructure as a Service，基礎(chǔ)設(shè)施即服務(wù)），即基于硬件虛擬化技術(shù)，為客戶提供虛擬化的服務(wù)器、數(shù)據(jù)庫及其他相關(guān)軟件、工具。
PaaS（Platform as a Service，平臺即服務(wù)），即客戶可以使用服務(wù)提供商所提供的編程語言、服務(wù)接口以及工具在特定的云基礎(chǔ)服務(wù)上構(gòu)建自定義的應(yīng)用程序。
SaaS（Software as a Service，軟件即服務(wù)），即客戶可以直接使用由服務(wù)提供商基于云基礎(chǔ)服務(wù)所構(gòu)建的特定應(yīng)用程序。
目前市面上大部分的公有云廠商都是部分或全功能的 IaaS 服務(wù)商，即可以為用戶提供特定的軟硬件虛擬化服務(wù)及相關(guān)的線上資源管理工具。
PaaS 作為云計算高層抽象的中間層，其具體的界定相對而言是比較曖昧的。它可以是像 AWS（Amazon Web Services）、GCP（Google Cloud Platform）、Azure（微軟的云計算平臺）這樣的，更偏向于IT基礎(chǔ)服務(wù)的全功能公有云計算平臺（這三巨頭均同時提供 IaaS 和 PaaS）；也可以是近年來有了迅猛發(fā)展的一些類似文件存儲、CDN、安全管理、容器服務(wù)以及營銷、游戲、媒體（直播、視頻）這樣的特定服務(wù)類 PaaS。
而 SaaS 則通常是現(xiàn)成的可用軟件，用戶只需要支付一定的“租金”就可以通過能接入互聯(lián)網(wǎng)的瀏覽器直接使用特定的業(yè)務(wù)功能，多數(shù) SaaS 都只需要很少的配置就可以在極短的時間內(nèi)開始為用戶提供具體服務(wù)。
很明顯，SaaS 模式與外包模式相比，其在成本上的優(yōu)勢非常巨大；同時因為其廠商多半對其應(yīng)用場景有較多、較深的經(jīng)驗，所以其具體業(yè)務(wù)功能的專業(yè)性通常也是比較高的。
針對 SaaS 產(chǎn)品的應(yīng)用范疇，我們還可以把 SaaS 分為以下兩類：
通用 SaaS，旨在解決各種企業(yè)中都可能需要的一些功能，比如溝通、安全管理、知識管理、文檔管理、考勤、差旅、審批（流程）、資產(chǎn)管理、會議管理之類。
垂直 SaaS，旨在解決一些細(xì)分領(lǐng)域或者行業(yè)特有的業(yè)務(wù)問題，比如特定行業(yè)的收費業(yè)務(wù)、電子商務(wù)、租賃、醫(yī)療（健康管理）、營銷、建筑工程、商業(yè)零售等等。
總體上說，通用 SaaS 的目標(biāo)客戶范圍更大，相對而言競爭也更多；而垂直 SaaS雖然客戶范圍變小了，但其客戶的同質(zhì)性更強，且因為其細(xì)分行業(yè)的專業(yè)性，從具體功能上看也會更有特點，更容易做深、做精（取決于服務(wù)商本身的業(yè)務(wù)領(lǐng)域能力及個性設(shè)計）。這兩類 SaaS 從其商業(yè)模式上看，并沒有本質(zhì)的區(qū)別。
SaaS 還是 PaaS
從實際情況來看，IaaS 和 SaaS 在企業(yè) IT 服務(wù)領(lǐng)域的應(yīng)用是最直接、最自然而然的。
IaaS 模式，是由專業(yè)的云計算廠商對基礎(chǔ)軟硬件（比如服務(wù)器、數(shù)據(jù)庫、網(wǎng)絡(luò)帶寬、備份、災(zāi)備等等）進行虛擬化來提供的。它與傳統(tǒng)的企業(yè) IT 管理方式相似度非常高，但一般而言，即使是大企業(yè)，在數(shù)據(jù)中心構(gòu)建、網(wǎng)絡(luò)優(yōu)化、異地災(zāi)備等方面的專業(yè)性也很難與專業(yè)的公有云計算廠商相比，要得到同級別的服務(wù)能力，成本至少要高出一個數(shù)量級。所以 IaaS 模式得到客戶的認(rèn)可是很自然的事。但I(xiàn)aaS 模式所解決的僅僅是一些必須的基礎(chǔ)IT軟硬件的持有和維護問題，用戶業(yè)務(wù)功能的實現(xiàn)，依然還需要通過外包模式來定制開發(fā)獲得，所以這實際上并不是顛覆性的。
當(dāng) SaaS 模式發(fā)展成熟之后，企業(yè)用戶在進行 IT 規(guī)劃時，才有了真正的另一個選項。因為 SaaS 提供的是直接可用的軟件，所以其在企業(yè)用戶的財務(wù)報表中僅僅表現(xiàn)為可預(yù)測的、低廉的“租賃”成本，而不是外包模式中所必須的、高昂的軟件開發(fā)費用、軟硬件購置費用和維護成本（包含相關(guān)的內(nèi)部人力成本）等等。
從本質(zhì)上說，外包模式是以較大的投入，換取一定的企業(yè)軟硬件資產(chǎn)；而 SaaS 模式僅僅是以較小的運營成本支撐企業(yè)的運轉(zhuǎn)，并不產(chǎn)生軟硬件資產(chǎn)。所以企業(yè)的選擇，更多的是判斷以至少超出一個量級的成本所得到的軟硬件資產(chǎn)是否值得去投入的問題。很明顯，一般而言，規(guī)模越小的企業(yè)，使用 SaaS 的意愿會越強，因為這有助于它們聚焦自己的業(yè)務(wù)，而不用去花費很多成本來創(chuàng)造一些沒有實際業(yè)務(wù)價值的軟硬件資產(chǎn)。對于大中型企業(yè)而言，SaaS 也并不是就沒有吸引力，因為這同樣也提供了一種可以使企業(yè)把研發(fā)、運營成本聚焦在關(guān)鍵業(yè)務(wù)的選項。
當(dāng)然，企業(yè)用戶對 SaaS 模式的擔(dān)心也是可以理解的。比如，采用 SaaS 模式之后，企業(yè)自有 IT 團隊勢必面臨一定程度的邊緣化和轉(zhuǎn)型壓力；以及最重要的，對業(yè)務(wù)數(shù)據(jù)（尤其是敏感商業(yè)數(shù)據(jù)）物理存儲位置的擔(dān)心。但這些問題其實都是企業(yè)IT規(guī)劃、IT 戰(zhàn)略轉(zhuǎn)型中的必然，也是可以從技術(shù)上、管理上解決的。
與大公司把持 IaaS 市場不同，SaaS 服務(wù)商的技術(shù)、資金門檻更低，而且作為一種新的產(chǎn)業(yè)增長點，SaaS 服務(wù)商也是創(chuàng)業(yè)公司和傳統(tǒng)的系統(tǒng)集成商、方案商乃至軟件外包公司的一個巨大的機遇。大概從 2010 年開始，歐美的 SaaS 服務(wù)商逐漸得到了廣泛的認(rèn)可和接受，紛紛做大乃至上市。而國內(nèi)的企業(yè) IT 服務(wù)市場還處于轉(zhuǎn)型的初期，大有可為。
SaaS 模式的弊端
SaaS 模式能否取得商業(yè)可行性的關(guān)鍵就在于能否快速復(fù)制、用戶能否在極短的時間內(nèi)就使用其提供的具體功能服務(wù)。這當(dāng)然要求 SaaS 的功能在不同用戶間具有極高的“相似度”，否則就無法快速復(fù)制、快速交付用戶。
但事實是，對于大中型企業(yè)而言，其核心業(yè)務(wù)的具體功能細(xì)節(jié)是很難達(dá)到“高度相似”的程度的。所以市場上能夠得到廣泛應(yīng)用的絕大多數(shù) SaaS 都不是企業(yè)的核心業(yè)務(wù)，而是一些通用型的、非業(yè)務(wù)功能性的基礎(chǔ)功能需求，比如 Slack、釘釘、企業(yè)微信所提供的那些功能。
Salesforce 提供的 CRM 功能，當(dāng)然屬于企業(yè)的核心業(yè)務(wù)之一，但它能得到很多大中型企業(yè)的采用，是因為它的復(fù)雜程度、功能的完整、完善程度實際上已經(jīng)不是一般意義上的 SaaS 了，它的產(chǎn)品實際上已經(jīng)做成了本文要安利的終極目標(biāo)——垂直 PaaS。
對于稍微大一些企業(yè)來說，一旦涉及到其重要的具體業(yè)務(wù)，必然會有很多的定制化需求，包括對本地部署（數(shù)據(jù)隱私性）的要求，這在國內(nèi)的老牌 ERP、CRM、財務(wù)軟件廠商那里已經(jīng)得到了印證。所以用 SaaS 模式來提供這些業(yè)務(wù)功能的服務(wù)，通常都不是一個可行的好主意，尤其是從國內(nèi)環(huán)境來看。
以我個人實際供職的最后兩家公司為例，一家是做企業(yè)級金融服務(wù)，一家是做智能樓宇管理服務(wù)。那么對于這種業(yè)務(wù)來講，其客戶的體量都不小，所以你要求客戶按照你自己設(shè)計的 SaaS 軟件的流程來走，是根本不現(xiàn)實的。即使能推進，也要根據(jù)客戶的要求做很多的定制，要適應(yīng)客戶自己的已有系統(tǒng)、已有廠商、已有規(guī)程。這在樓宇管理這種業(yè)務(wù)中體現(xiàn)得尤為明顯。絕大多數(shù)客戶都不可能因為簽約了一家管理平臺 SaaS 廠商，就把自己已有的所有管理系統(tǒng)全替換掉，就把自己已經(jīng)使用的所有相關(guān)設(shè)備廠商全替換掉，所以你的 SaaS 必然要支持客戶目前的各種業(yè)務(wù)系統(tǒng)、各種流程、各種廠商的設(shè)備。顯然，目前各個廠商的標(biāo)準(zhǔn)化程度是極低的，所以你的 SaaS 里就必然的會出現(xiàn)非常多的定制化邏輯。這會極大增加 SaaS 軟件的開發(fā)成本和維護成本。SaaS 廠商做到最后會發(fā)現(xiàn)實際上 SaaS 已經(jīng)不是 SaaS 了，而是定制化的項目的集合，變成了費力不討好的系統(tǒng)集成業(yè)務(wù)。這對初創(chuàng)公司而言無異于“毒藥”，因為你沒辦法快速復(fù)制；換一個客戶，又是一堆定制化的需求，那 SaaS 實施的成本優(yōu)勢也就不存在了，整個商業(yè)模式也就不成立了。
評判一個 SaaS 軟件的標(biāo)準(zhǔn)，最簡單的當(dāng)然就是看它在不同客戶企業(yè)中實施時所必須的代碼改動量。代碼零改動當(dāng)然是所有 SaaS 廠商的目標(biāo)，但顯然并不都能做到。問題就在于這個代碼改動量給實施和后期運維所帶來的額外成本，能否用訂閱模式的“租金”來覆蓋；在于客戶量逐漸變大之后，總體的“租金”收入能否持續(xù)地覆蓋這部分額外成本。如果不能，那就要看有多少錢來支撐你的 SaaS 產(chǎn)品達(dá)到零代碼修改的程度。
采用 PaaS 模式能帶來哪些變化
從前文中對 PaaS 的解釋可以看到，PaaS，是由服務(wù)商提供的一種可以“自定義應(yīng)用程序”的工具，而不是可以直接使用的軟件。我們可以把 PaaS 想象成為樂高積木，用戶可以根據(jù)自己的需求、設(shè)計來自由地組合、拼接出的自己想要的物體。
目前市面上的公有云廠商提供的主要 PaaS 特性，比如應(yīng)用引擎（例如 Google 的App Engine、AWS 的 Elastic Beanstalk）、云數(shù)據(jù)庫（并不是簡單的數(shù)據(jù)庫產(chǎn)品虛擬化，而是可以由 API 控制的、具有動態(tài)伸縮性的、高吞吐量的所謂“全托管”數(shù)據(jù)庫產(chǎn)品，例如 AWS 的 Aurora、DynamoDB）、云存儲（例如 Amazon 的 S3、阿里云的 OSS）、內(nèi)容分發(fā)（CDN）、網(wǎng)絡(luò)（VPC）、媒體服務(wù)（直播、視頻）、監(jiān)控工具、AI 基礎(chǔ)服務(wù)工具以及函數(shù)計算、無服務(wù)器（serverless）計算（例如 AWS Lambda）等等，這些都是更偏向于 IT 基礎(chǔ)服務(wù)的高級抽象，也就是更接近于 IaaS 的 PaaS。但它們并不能直接用來簡單地拼接、搭建可用的業(yè)務(wù)系統(tǒng)，因為它們并沒有對任何具體的業(yè)務(wù)邏輯進行抽象；當(dāng)然，這也不是公有云廠商應(yīng)該做的事，再大的廠商也不可能通吃所有的具體業(yè)務(wù)場景。
所以，對企業(yè) IT 服務(wù)來講，更接近 SaaS 的 垂直 PaaS 才是企業(yè)用戶的樂高積木。而這也才是企業(yè) IT 服務(wù)商可以有所作為的終極形態(tài)！
什么是垂直 PaaS
所謂垂直 PaaS，就是一種針對細(xì)分領(lǐng)域、特定業(yè)務(wù)場景而設(shè)計抽象的 PaaS。垂直 PaaS 會提供一套可以實現(xiàn)某項具體業(yè)務(wù)功能的技術(shù)接口（也就是一套原子化的業(yè)務(wù)功能操作集合），用戶可以自由組合、使用這些技術(shù)接口，在自己的內(nèi)部業(yè)務(wù)系統(tǒng)、產(chǎn)品平臺以及各端應(yīng)用（移動設(shè)備 App、瀏覽器插件等等）中以自定義的方式，簡單、直接地實現(xiàn)具體的業(yè)務(wù)功能。
從概念上，可以把垂直 PaaS 理解為：把某個具體的 SaaS 的前端用戶交互邏輯拿掉，把業(yè)務(wù)處理和一些通用基礎(chǔ)服務(wù)（比如身份驗證、用戶權(quán)限管理、元數(shù)據(jù)管理、文件/文檔數(shù)據(jù)服務(wù)等等）抽象為原子化的 API 提供出來的一種云計算服務(wù)。
SaaS 在大中型企業(yè)中應(yīng)用的一些主要問題（比如，SaaS 一般需要一套單獨的用戶賬戶、單獨的業(yè)務(wù)數(shù)據(jù)；操作界面、操作流程是服務(wù)商預(yù)設(shè)好的，無法整合到已有的業(yè)務(wù)系統(tǒng)、或者現(xiàn)有的業(yè)務(wù)流程中等等），在垂直 PaaS 中都可以相對完美地解決：因為垂直 PaaS 提供的是原子化的、解耦的業(yè)務(wù)操作技術(shù)接口，所以可以很容易地集成到現(xiàn)有系統(tǒng)、現(xiàn)有流程中，甚至用戶賬戶、元數(shù)據(jù)（業(yè)務(wù)數(shù)據(jù)）都可以通過技術(shù)接口進行方便的初始化（數(shù)據(jù)定義）、導(dǎo)入導(dǎo)出、格式變換等等。
垂直 PaaS，是一種支持“自定義應(yīng)用程序”的、針對某個具體業(yè)務(wù)功能的技術(shù)平臺，要使用它，必然需要有技術(shù)能力的“人”來做一定的開發(fā)或者集成，而做開發(fā)的“人”，既可以是用戶、企業(yè)自己的開發(fā)團隊，也可以是系統(tǒng)集成商、方案商、軟件外包商乃至個人開發(fā)者。所以作為垂直 PaaS 服務(wù)商，其發(fā)展方向就很明確了：技術(shù)上，不斷完善平臺功能，做深、做精，甚至創(chuàng)造自己的開發(fā)語言、開發(fā)工具，進而構(gòu)建開發(fā)者社區(qū)，建立應(yīng)用市場、插件市場，逐步完善生態(tài)系統(tǒng)；商業(yè)模式上，在自主推廣的同時，積極尋求有遠(yuǎn)見的集成商、方案商、外包商合作伙伴，共同擴展客戶市場，實現(xiàn)共贏。與 SaaS 模式相比，這顯然是更有想象空間的。
只有大公司才能做 PaaS 嗎
恰恰相反，“只有做了 PaaS 的公司，才可能成為大公司”。
當(dāng)然，長期看來，垂直 PaaS 產(chǎn)品的研發(fā)成本肯定要高于 SaaS 產(chǎn)品，但在構(gòu)建初期，其差距并不像想象中那么巨大。目前的大多數(shù) SaaS 產(chǎn)品都應(yīng)該是前后端分離的了，那么基于這個前提，垂直 PaaS 就可以看作是把某個 SaaS 的后端調(diào)用接口開放出來給用戶直接使用，以達(dá)到靈活的調(diào)用、組織和集成這些特性。只是，要把后端接口完全開放，肯定會需要一些額外的設(shè)計，以及對業(yè)務(wù)處理的原子化抽象；因為普通的 SaaS 產(chǎn)品，其后端接口多半是與前端表示邏輯相關(guān)的，要開放這些接口，就要把與表示邏輯相關(guān)的部分拿掉，這樣做的結(jié)果有時會產(chǎn)生完全不同的業(yè)務(wù)處理接口。
所以對于初創(chuàng)公司來說，如果你志在以 SaaS 的方式做企業(yè)服務(wù)，那么將 SaaS 的后端接口 PaaS 化，就是你應(yīng)該在最開始就去做的事。這當(dāng)然會多花費一些成本，但還不至于難以支撐，因為該做的具體功能其實沒有多大差別，只需要你有個“會設(shè)計 PaaS”的架構(gòu)師就好了。
這里對垂直 PaaS 和 SaaS 后端設(shè)計的區(qū)別的描述是概念性的，具體實操時有一些設(shè)計原則和技術(shù)細(xì)節(jié)問題需要討論，但限于文章的篇幅，這里就不再展開了，而且這也已經(jīng)超出了本文的范疇。
有了 PaaS 化的后端之后，想做一套前端就比較簡單了，你甚至可以把前端的開發(fā)外包給更有前端經(jīng)驗的公司去做。如果你這么做了，那這個公司就極有可能成為你未來的可選集成商，他的客戶就有可能成為你的客戶，你的客戶也可能成為他的客戶；這就是一種共贏的模式。有了 PaaS 化的后端之后，你自己做一套預(yù)設(shè)好的前端，作為 SaaS 提供給客戶直接使用；或者你去幫客戶進行集成、給客戶定制他們自己的前端也就都是自然而然的可選項了。這也顯然是比單純地提供 SaaS 服務(wù)更有競爭力的模式。
對于初創(chuàng)公司而言，你大可采用一些大的公有云廠商的高服務(wù)等級、高安全等級的 IaaS 服務(wù)（比如 AWS 提供的很多全托管的基礎(chǔ)設(shè)施服務(wù)）去搭建你自己的垂直 PaaS，這對于初創(chuàng)公司而言有很好的靈活性和很高的資金利用率，等到未來有了資金、資源之后再考慮自建相關(guān)服務(wù)乃至數(shù)據(jù)中心。
SaaS（垂直 PaaS）是初創(chuàng)公司的機會還是毒藥
首先我們來看看兩家企業(yè) IT 服務(wù)領(lǐng)域最具代表性的垂直 PaaS 廠商的情況。
Salesforce
這個成立于 1999 年的老牌 SaaS 廠商，目前其市值已經(jīng)超過 1300 億美元，在企業(yè) IT 服務(wù)領(lǐng)域僅次于 Oracle（1700 億美元） 和 SAP（1400 億美元），是最大的在線 CRM 廠商。直到現(xiàn)在，它仍然是 SaaS 領(lǐng)域的領(lǐng)導(dǎo)者。
大概從 2003 年左右，Salesforce 就開始構(gòu)建起生態(tài)系統(tǒng)，包括改造后端系統(tǒng)、逐年擴大社區(qū)規(guī)模。2004 年，Salesforce 在 Nasdaq 上市。2005 年，發(fā)布了應(yīng)用市場 AppExchange，這也被業(yè)內(nèi)稱為“商用軟件的 eBay”或者“商用軟件的 iTunes”。緊跟著在 2006 年，Salesforce 發(fā)布了公共開發(fā)語言 Apex，允許客戶、合作伙伴和開發(fā)者使用其創(chuàng)建“企業(yè)主導(dǎo)的按需服務(wù)”程序。到 2008 年，其 PaaS 產(chǎn)品“Force.com”正式發(fā)布，也標(biāo)志著其生態(tài)系統(tǒng)的構(gòu)建完成。
如果說先入優(yōu)勢是其前 10 年成長壯大的主要因素的話，那么以 PaaS 產(chǎn)品為核心的生態(tài)系統(tǒng)，就是其后 10 年飛速發(fā)展的堅實基礎(chǔ)。
Slack
Slack 是一款團隊協(xié)作工具和服務(wù)平臺，于 2013 年 8 月發(fā)布了 beta 版本，在其前兩年的發(fā)展中飽受 bug 和頻繁更新的困擾，但其優(yōu)秀的用戶體驗、人性化的細(xì)節(jié)設(shè)計也迅速征服了用戶。僅僅用了 3 年時間，Slack 就登上了福布斯 Cloud100榜單（還未上市的云計算廠商熱度排名）的頭名。2017 年，Slack 在 Cloud100 中名列第三（其估值已經(jīng)超過50億美元），前兩名是 Stripe 和 Dropbox。
Slack 是目前最好的協(xié)作和工具集成平臺（工具類垂直 PaaS），其主要特性包括：在線溝通（參考 QQ 或 TIM 中的群、討論組、即時消息、個人狀態(tài)等等）、內(nèi)容搜索（Slack 內(nèi)的所有資源都是可直接搜索的，包括文檔、話題、消息歷史、用戶等等）、流式的集成消息工作區(qū)（一種將所有集成工具、服務(wù)的內(nèi)容“流”化而成的信息流工作區(qū)，可以集成包括 Google Drive、Dropbox、Github、Jira、Salesforce、Zendesk、Twitter 在內(nèi)的數(shù)百種第三方在線服務(wù)，并且可以自定義開發(fā)，由其提供的 App Directory 進行發(fā)布和管理）。
Slack 的流式消息工作區(qū)，其后端實際上是一種定制化的垂直 PaaS，可以與同樣提供了 PaaS 接口的第三方 SaaS/垂直 PaaS 進行簡單的技術(shù)集成，從而在 Slack預(yù)設(shè)的界面中用統(tǒng)一的形式展示給用戶。
垂直 PaaS 是企業(yè) IT 服務(wù)的銀彈么
我想系統(tǒng)集成、SaaS、垂直 PaaS 依然將是中長期會并存的解決方案，因為它們的實際目標(biāo)客戶并沒有太多沖突。而且技術(shù)方案從來都不是最重要的因素。
別的公司都做 PaaS 了，我們要不要做？這個問題就像是：別的公司都做微服務(wù)了，我們要不要做？別的公司都搞中臺了，我們要不要搞？其實所有的架構(gòu)、技術(shù)都是為業(yè)務(wù)服務(wù)的，都是為了解決某些具體問題的，本質(zhì)上都是組織的演進和變革。如果你都不知道自己的企業(yè)/組織有什么問題，不知道瓶頸在哪里，那你怎么改也都是東施效顰，只是多浪費一些錢或者死的更快而已。
所以最重要的，就是搞明白一個產(chǎn)品的業(yè)務(wù)目標(biāo)，搞清楚你是想解決什么問題。如果你要推動其他企業(yè)的組織形式、管理方式的變革，那你就要考慮自己的產(chǎn)品如何適應(yīng)那些千奇百怪的定制化需求，就要考慮你能否將復(fù)雜的功能需求抽象為可實現(xiàn)的數(shù)據(jù)模型和控制模型以便能夠快速地復(fù)制或定制；那么你的產(chǎn)品形態(tài)也就自然地應(yīng)該成為垂直 PaaS。如果你的目標(biāo)只是去解決某個具體的、與業(yè)務(wù)無關(guān)或低相關(guān)的問題，比如溝通、協(xié)作、共享、具體工作內(nèi)容支持等等，那做 SaaS 就夠了。
產(chǎn)品形態(tài)影響的是內(nèi)部效率和中長期的成本，你的義務(wù)閉環(huán)能否成立還是要看商業(yè)模式和財務(wù)模型。在軟件工程或架構(gòu)設(shè)計層面，當(dāng)然不存在“銀彈”這種東西。
初創(chuàng)公司的失敗有很多原因，對業(yè)務(wù)目標(biāo)定位不清或者頻繁搖擺將是直接致命的，因為這將直接影響你的技術(shù)決策。雖然軟件重構(gòu)、再設(shè)計的成本和可行性遠(yuǎn)低于實體工程，但對于初創(chuàng)公司而言，依然是難以承受的，除非你有巨額的或者持續(xù)的資金支持去不斷試錯；即便如此，這也是對研發(fā)/實操團隊和投資人耐心的巨大考驗。比如你把 SaaS 產(chǎn)品做成了實施項目的集合、到處是定制化功能、到處 hard code，這在擴展和后期維護上帶來的隱形成本必將使你無以為繼；客戶越多，死的越快。沒有產(chǎn)品平臺支撐的快速擴張無異于自殺。即使不馬上死，也會陷入系統(tǒng)集成商們的窘境，變成軟件勞動力輸出，難以做大做強。
企業(yè) IT 服務(wù)這個市場沒有問題，因為大多數(shù)企業(yè)的信息化、規(guī)范化都存在提升的空間和意愿；問題在于初創(chuàng)公司如何選擇合適的切入點，如何確定對自己最有利的產(chǎn)品形態(tài)。但這個問題的答案就只能靠創(chuàng)業(yè)者自己去探索找尋了。
垂直 PaaS 的設(shè)計和實現(xiàn)當(dāng)然不簡單，對研發(fā)團隊人員的要求也是很高的；但這方面的話題已經(jīng)超出了本文的范疇，未來有機會我們再另行撰文討論。（來源：倚杖聽江聲 文/楊鎮(zhèn) 編選：網(wǎng)經(jīng)社）
